home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / June 96 / Re RE>Script editing within Op < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.5 KB  |  [TEXT/ttxt]

  1. Subject:     Re: RE>Script editing within OpenDoc (was: Notification when a 
  2. Sent:        6/4/96 1:12 PM
  3. Received:    6/4/96 1:21 PM
  4. From:        Jon Pugh, jonpugh@netcom.com
  5. Reply-To:    OpenDoc-Interest@CILabs.ORG
  6. To:          OpenDoc Related Technologies Interest List, OpenDoc-Interest@CILabs
  7.  
  8. At 3:15 PM 6/4/96, Rob Cope wrote:
  9. >In the case of a script, I want to have something generic that I can run
  10. >and hand to any editor to edit/debug.  I believe Brad's idea (please
  11. >correct me if I am wrong) was to store text that would be compiled and run
  12. >by his part.  To edit the script, he would create an ODStorageUnit with a
  13. >text property, and bind a text editor to it.  At some point (window close
  14. >in his scheme) he would pull the data out of the text property and compile
  15. >it.
  16.  
  17. This is probably more complicated than necessary.  Right now we typically
  18. store the script as a resource in script files.  It would make sense to
  19. store it in a storage unit instead.  It might also make sense to provide
  20. either a seperate representation of the script in text or a trivial method
  21. of converting the script to text, which is how script editors display the
  22. styled text.  I'm not sure how to do the latter in OpenDoc.  It's not hard
  23. in the OSA, I just don't know enough about the translation services in
  24. OpenDoc yet.  I guess I'll go read some documentation.  ;)
  25.  
  26. >It sounds like your point is that "text" is not the proper object, because
  27. >the part cannot handle compile errors, debugging, libraries, etc.  So what
  28. >we need is a generic script object that any script editor could
  29. >edit/debugg, and that interested parts (like a button) could execute
  30. >without having to have the editor that created it (though they might need
  31. >to pass error info off to one).  Does that sound reasonable to you?  Does
  32. >that sound like something that needs to be invented, or does the correct
  33. >data type already exist (I'm not an AppleEvent expert yet)?
  34.  
  35. Yes, I think the proper thing is to create a standard type for scripts and
  36. use that as the base storage unit.  Then you can add other "value-added"
  37. properties to the storage unit for customization.  If those got
  38. standardized among script editors, that would be even better.
  39.  
  40. We can defined the standard script storage unit format immediately since it
  41. will be the same as the current resource format.  All it needs is a name,
  42. and I'll bet there's one already defined.  Hmm, "kODCategoryScript" looks
  43. promising.  I wish I hadn't slept through that OpenDoc course about now.
  44. ;)
  45.  
  46. Jon
  47.  
  48.